Users of connection-oriented communications networks, of the type typically used to connect telephones or computers, communicate by first establishing a “call”. A call represents an agreement to communicate over a particular path, where a path is a series of links between network entities. From a network management perspective, each call is a billable entity. Call establishment and teardown is typically implemented through the use of a “call” protocol that is used for communication between an entity representative of a user and an entity representative of a network through which the call is to be established. The call protocol may also be used for communication between entities within networks and between entities in separate networks. A “connection” may be considered the actual “pipe” over which user communication flows. Once a call is established or while a call is being established, a connection may be established and associated with that call. In general, there may be zero or more connections associated with a single call. One of the important functions of the call protocols is the initiation and management of “connection establishment” protocols. 
A Call Controller is a call control entity that is used to initiate, terminate and transit call actions. The Call Controller enables the establishment, release, modification and maintenance of individual calls or sets of calls. When in use by a user, the Call Controller is known as a “Client” Call Controller. When in use at a network edge and a border between networks, the Call Controller is known as a “Network” Call Controller. Many Call Controllers are involved in a single call. The Call Controllers that are involved in the same call communicate with each other, using a predetermined protocol, to control and maintain the connections associated with the call. Typically, call control entities that are not involved in the same call do not communicate with each other in connection-oriented networks.
To establish a call, a Client Call Controller communicates with a Network Call Controller (a source network entity) to indicate a requirement for a call and a destination for the required call. This requirement is often indicated through the use of a “call request” message, which is part of a protocol that defines standard call processing messages. In typical connection-oriented networks with distributed call and connection control, such as described above, a path is computed, by the Network Call Controller that received the call request message from the Client Call Controller, for the required call without consideration of information relating to other, previously established, calls in the network. While information relating to calls that originate from a given Network Call Controller is available to the given Network Call Controller while calculating a path for a new call, information relating to calls that originate from other Network Call Controllers is not available to the given Network Call Controller.
It has been suggested that additional information, of a scope larger than the given Network Call Controller normally processes, should be made available to the given Network Call Controller in order to constrain call establishment. Where properly constrained calls are established, it is suggested that the connection-oriented network involved will operate more efficiently.
This additional information could include information relating to other calls and the connections associated with those other calls. The additional information could also  include information relating to gateways to adjacent networks and the call controllers in adjacent networks that may be associated with specific Client Call Controllers.
One approach for providing additional information involves allowing a Client Call Controller to query a first Network Call Controller for information relating to a first call established through communication with the first Network Call Controller. It would then be expected that the first Network Call Controller would release this information to the querying Client Call Controller. The information may then be used by the Client Call Controller when sending a call request message, for a second call, to a second Network Call Controller. The Client Call Controller may pass the information to the second Network Call Controller in order that the second call may be constrained by the information passed about the first call.
The problem with this approach is that the first Network Call Controller could disclose, to the Client Call Controller, some network information that should remain confidential. Typically, the relationship between users (Client Call Controllers) and networks (Network Call Controllers) is considered to be an “untrusted” relationship. In this approach, wherein a Client Call Controller can learn network information about a call through a query, the untrusted nature of the user-network relationship is broken. That is, a first entity is sending information to a second entity that the first entity would not normally send, due to the nature of the relationship between the two entities.
A second approach involves the introduction of a global call identifier that can be accessed by more than one source network entities, that is, Network Call Controllers that will be establishing calls in the future. Where a source Client Call Controller has requested, of a first Network Call Controller, that a first call be established to a destination, the established call is given a global call identifier, which is disclosed to the source Client Call Controller. Further, network information about the first call may be maintained at a central entity in the network. The source Client Call Controller may then use the global call identifier of the first call when requesting, of a second Network Call Controller, that a second call be established to the same destination, where the path of the second call is to be diverse from the path of the first call. A path may be considered  diverse relative to another path if the two paths do not have any path segments in common. Additionally, a path may be considered diverse relative to another path if the two paths do not have any intermediate path segment end points (nodes) in common. However, this approach is not always efficient. A path for the second call might never be found, since availability of alternate paths is not considered at the time of establishment of the first call. Furthermore, the central entity may be required to retain information relating to calls and connections associated with those calls in a network and between networks. Without a centralized call/connection database, path computation may occur without information relating to path segments or intermediate path segment end points to avoid. Only when the path computation process encounters a node acting as an end of a path segment in use by a call having the global call identifier of the first call, can path computation know to try a path that does not include that path segment or intermediate point. Unfortunately, neither approach, i.e., the centralized call/connection database approach and the approach without a database, may be performed with speed sufficient to meet various path computation guidelines, even in a single network.
A third approach involves creating a separate method, strictly for inter-Call Controller communication. However, inter-Call Controller communication usually piggybacks on connection control communication and it is preferred that Call Controllers be able to communicate with each other in the absence of previously established calls. Additionally, Call Controllers in different networks may have difficulty communicating given that there may be no shared signaling network between those networks.
Clearly, a need exists for Call Controllers to communicate in a manner that provides the Call Controllers with additional network information, yet avoids revealing network information to the user and avoids use of direct communications between Call Controllers that is separate from existing communications.